Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-frnetmib-fr-00.txt < prev next >

Wrap

Text File | 1993-06-07 | 66.1 KB | 2,301 lines

Internet Draft Frame Relay Service MIB May 12, 1993 Definitions of Managed Objects for Frame Relay Service May 12, 1993 Frame Relay Service MIB Working Group Tracy A. Cox (editor) Bell Communications Research 331 Newman Springs Road Red Bank, NJ 07701 tacox@mail.bellcore.com 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 2. Abstract This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. This memo does not specify a standard for the Internet community. T. Cox (editor) Expires 12/31/93 [Page 1] Internet Draft Frame Relay Service MIB May 12, 1993 3. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213, defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements. RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. T. Cox (editor) Expires 12/31/93 [Page 2] Internet Draft Frame Relay Service MIB May 12, 1993 4. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 4.1. Format of Definitions Section 6 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in RFC1212 [9]. T. Cox (editor) Expires 12/31/93 [Page 3] Internet Draft Frame Relay Service MIB May 12, 1993 5. Overview These objects are used when the particular media being used to managed Frame Relay Service. At present, this applies to these values of the ifType variable in the Internet-standard MIB: frame-relay (32) This section provides an overview and background of how to use this MIB and other potential MIBs when managing a Frame Relay Service. The following diagram shows the MIB stack that could be followed for managing a Frame Relay Service. This is only an example and not meant to be inclusive. _____________________________________ | | | MIB II | |___________________________________| | | | | | Frame Relay | SIP | RFC1294 | | X.25 MIB | Relay | (no applic.| | for IW/Encap.| MIB | MIB) | | | | | |-----------------------------------| | | | Frame Relay Service MIB | |___________________________________| | | | | Physical Layer MIBs | ATM MIB | | e.g., DS1/E1 MIB, |---------| | RS232-like MIB | Phy. | | | Layer | | | MIB | |-------------------------|---------| SCOPE OF MIB: The Frame Relay Service MIB will only manage the Frame Relay portion of the network and will provide a pointer to the lower layer MIB (for example, a physical layer MIB or the ATM MIB) for each UNI/NNI access channel. This MIB will NOT be implemented on User Equipment. T. Cox (editor) Expires 12/31/93 [Page 4] Internet Draft Frame Relay Service MIB May 12, 1993 Frame Relay Service SNMP MIB for Customer Network Management (CNM) is an SNMPv1 MIB. It provides read-only information that allows end-customers to obtain performance monitoring, fault detection, and to obtain performance monitoring, fault detection, and configuration information about their Frame Relay Service. By using this and other related MIBs, a customer's NMS can monitor their PVCs and UNI/NNI access channels. Internal aspects of the network (e.g., switching elements, line cards, and network routing tables) are outside the scope of this MIB. The Customer's NMS will be able to access the SNMP agent within the Frame Relay network using SNMP over UDP over IP with IP encapsulated in Frame Relay according to RFC1294/ANSI T1.617 Annex F. The customer thus has a PVC to the SNMP agent. Alternate access mechanisms are possible. The initial implementation of the MIB is based on SNMPv1. The service capabilities include retrieving information and receiving TRAPs. It is beyond the scope of this MIB to define managed objects to monitor the physical layer. Existing physical layer MIBs (e.g., DS1 MIB) and MIB II will be used as possible. The Frame Relay Service SNMP MIB for CNM will not contain any managed objects to monitor the physical layer. However, the Frame Relay Service SNMP MIB for CNM will contain a pointer to the appropriate lower layer MIB for each UNI/NNI access channel. To the maximum extent as possible, PVCs and SVCs will be treated equally in the MIB. The Frame Relay Service MIB will only manage the Frame Relay portion of the network and will provide a pointer to the lower layer MIB (for example, a physical layer MIB or the ATM MIB) for each UNI/NNI access channel. 5.1. Apply MIB II to a Frame Relay Service Use the System Group to apply to the SNMP agent/proxy-agent, since the agent/proxy-agent may be monitoring many Frame Relay devices in one network. System Group applies to only one system. This group is not instantiated. sysDescr: ascii string describing the SNMP agent/proxy-agent. can be only up to 255 characters long. sysObjectID: unique OID for the SNMP agent/proxy-agent. sysUpTime: clock in the SNMP agent/proxy-agent; TimeTicks T. Cox (editor) Expires 12/31/93 [Page 5] Internet Draft Frame Relay Service MIB May 12, 1993 in 1/100s of a seconds sysContact: Contact for the SNMP agent/proxy-agent ascii string of up to 255 characters sysName: Domain name of the SNMP agent/proxy-agent, for example, mail.bellcore.com sysLocation: Location of the SNMP agent/proxy-agent ascii string of up to 255 characters sysServices: services of the managed device; suggest using the value "2" which implies that the Frame Relay service is providing a subnetwork level service Use the Interface Group to apply to the FR-UNIs and the FR- NNIs of the Frame Relay service. This group is instantiated by ifIndex. ifIndex: unique identifier for the UNI/NNI access channel ifDescr: ascii string describing the UNI/NNI access channel, can be only up to 255 characters long. ifType: identifies the service below the network layer and is used to identify the MIB below MIB II as shown in the figure above. "32" for frame-relay ifMtu: size of largest SDU size for frame-relay for this UNI/NNI access channel, e.g., "1600" ifSpeed: actual user information transfer rate of the UNI/NNI access channel in bits per second e.g., 1536000 bits per second for a DS1-based FR-UNI and 1948000 bits per second for an E1-based FR-UNI. ifAdminStatus: the administrative status of the UNI/NNI access channel ifOperStatus: the operational status of the UNI/NNI access channel ifLastChange: Timestamp of the last time something changed on the UNI/NNI access channel T. Cox (editor) Expires 12/31/93 [Page 6] Internet Draft Frame Relay Service MIB May 12, 1993 ifSpecific: OID pointing to the top of the Frame Relay Service MIB 5.2. Apply the DS1/E1 MIB to Frame Relay Service Use the DS1/E1 MIB (RFC1406) to manage DS1/E1 UNI/NNI access channels. The ifIndex value from the UNI/NNI access channels group will be used to identify the Frame Relay network UNI/NNI access channel. For a Frame Relay DS1/E1 or DS3/E3 UNI/NNI access channel (either FR-UNI or FR-NNI): ifIndex = dsx1LineIndex = dsx1IfIndex ifIndex = dsx3LineIndex = dsx1IfIndex mandatory groups are: dsx1ConfigTable dsx1CurrentTable dsx1IntervalTable dsx1TotalTable optional groups are: dsx1FarEndCurrentTable dsx1FarEndIntervalTable dsx1FarEndTotalTable If the T1/E1 UNI/NNI access channel supports fractional subrates then the dsx1FracTable should be supported to identify the channels within the T1/E1 line. The indices are as follows: In this case ifIndex does not equal dsx1LineIndex BUT: dsx1LineIndex = dsx1FracIndex ifIndex = dsx1FracIfIndex dsx1IfIndex is not used (noSuchName) T. Cox (editor) Expires 12/31/93 [Page 7] Internet Draft Frame Relay Service MIB May 12, 1993 The following provides an example of how the indexing works for the DS1 MIB and MIB II: For example: A Frame Relay Switch has three DS1 interfaces: DS1 Line 1 has 3 channels defined, Channel 1 uses timeslots 1-2, Channel 2 uses timeslots 3-5, Channel 3 uses timeslots 6-7, Remaining timeslots unused. DS1 Line 2 has 2 channels defined, Channel 1 uses timeslots 1-3, Channel 2 uses timeslots 4-7, Remaining timeslots unused. DS1 Line 3 has 1 channel defined, Channel 1 uses timeslots 1-24, All timeslots used. You have 3 DS1 interfaces off the frame relay network. You also have 6 access channels that are distributed across those 3 interfaces. Those six access channels map to an ifIndex value in MIB II. Each channel should have: ifIndex = 1; ifType = frame-relay ifIndex = 2; ifType = frame-relay ifIndex = 3; ifType = frame-relay ifIndex = 4; ifType = frame-relay ifIndex = 5; ifType = frame-relay ifIndex = 6; ifType = frame-relay (and the other applicable ifTable information) Next, Line 1 and 2 are fractional interfaces, whereas, Line 3 is not. Therefore, let's start with what is called Line 3. DS1 Line 3 has 1 channel defined, Channel 1 uses timeslots 1-24, All timeslots used. From RFC1406, T. Cox (editor) Expires 12/31/93 [Page 8] Internet Draft Frame Relay Service MIB May 12, 1993 (let's ignore RFC1406 Section 3.1, because for the case where the router proxies for the CSU and you would want to manage both internal (router side) and external (network side) DS1 interfaces), for Line 3: dsx1LineIndex = dsx1IfIndex = ifIndex = 1 for this interface the fractional table is not supported, and there is a one-to-one correspondence between a DS1 Line and an access channel. Looking at the example and the dsx1ConfigTable, this table is not very "friendly" for fractional DS1 interfaces. For fractional DS1 interfaces, there is NOT a 1-to-1 relationship between an ifIndex value ( = dsx1IfIndex) and dsx1LineIndex, but the table forces there to be one. Rightly so because, the table should only be used to manage DS1 interfaces once. But what to do when you have multiple ifIndices for that one dsx1LineIndex? I suggest return noSuchName for dsx1IfIndex when supporting a fractional T1 interface. Remember dsx1IfIndex = ifIndex always. Line 1 and Line 2 support fractional interfaces. By reading the description of dsx1LineIndex in the dsx1ConfigTable: "This object is the identifier of a DS1/E1 Interface on a managed device. If there is an ifEntry that is directly associated with this and only this DS1/E1 interface, it should have the same value as ifIndex. Otherwise, number the dsx1LineIndices with an unique identifier following the rules of choosing a number that is greater than ifNumber and numbering the inside interfaces (e.g., equipment side) with even numbers and outside interfaces (e.g, network side) with odd numbers." Therefore, using this rule, the DS1 lines can be labeled the following way: Line 1 => dsx1LineIndex = 7 Line 2 => dsx1LineIndex = 9 (because they do not correspond with one and only one ifIndex.) T. Cox (editor) Expires 12/31/93 [Page 9] Internet Draft Frame Relay Service MIB May 12, 1993 Remember that this is only an index and is not used for anything else but to index the DS1 line and it is NOT equal to ifIndex for this case. for these two cases; dsx1LineIndex =7 and 9; (Remember for these two cases dsx1IfIndex.7 = noSuchName and dsx1IfIndex.9 = noSuchName) therefore go to fracTable: dsx1FracIndex = dsx1LineIndex always Line 1 has 3 channels defined, Channel 1 uses timeslots 1-2, Channel 2 uses timeslots 3-5, Channel 3 uses timeslots 6-7, Remaining timeslots unused. dsx1LineIndex=7 dsx1FracIfIndex.7.1=2 (ifIndex=2) dsx1FracIfIndex.7.2=2 dsx1FracIfIndex.7.3=3 (ifIndex=3) dsx1FracIfIndex.7.4=3 dsx1FracIfIndex.7.5=3 dsx1FracIfIndex.7.6=4 (ifIndex=4) dsx1FracIfIndex.7.7=4 I think the description of dsx1FracIfIndex is wrong when it says "If no interface is currently using a channel, the value should be zero." But, because dsx1FracIfIndex is defined as INTEGER (1..'7fffffff'h) ^ you can NOT have an Index = 0; I would say return noSuchName for dsx1FracIfIndex.7.8 through dsx1FracIfIndex.7.24 Next: Line 2 has 2 channels defined, Channel 1 uses timeslots 1-3, Channel 2 uses timeslots 4-7, Remaining timeslots unused. dsx1LineIndex=9 dsx1FracIfIndex.9.1=5 (ifIndex=5) T. Cox (editor) Expires 12/31/93 [Page 10] Internet Draft Frame Relay Service MIB May 12, 1993 dsx1FracIfIndex.9.2=5 dsx1FracIfIndex.9.3=5 dsx1FracIfIndex.9.4=6 (ifIndex=6) dsx1FracIfIndex.9.5=6 dsx1FracIfIndex.9.6=6 dsx1FracIfIndex.9.7=7 again: I would say return noSuchName for dsx1FracIfIndex.9.8 through dsx1FracIfIndex.9.24 5.3. Frame Relay Service MIB Terminology Backward - Backward direction data traffic is traffic flowing from the terminating access channel to the originating access channel. This is illustrated in Figure 2. Access Channel - An access channel generically refers to the UNI access channel or NNI access channel across which frame relay data transmits. An access channel is the access pathway for a single stream of user data. Within a given T1 line, an access channel can denote any one of the following: o Unchannelized T1 - the entire T1 line is considered an access channel. Each access channel is comprised of 24 T1 time slots. o Channelized T1 - an access channel is any one of 24 channels. Each access channel is comprised of a single T1 time slot. o Fractional T1 - an access channel is a grouping of N T1 time slots (NX56/64 Kbps, where N = 1-23 T1 Time slots per FT1 Access Channel) that may be assigned in consecutive or non-consecutive order. Within a given E1 line, a channel can denote any one of the following: o Unchannelized E1 - the entire E1 line is considered a single access channel. Each access channel is comprised of 31 E1 time slots. o Channelized E1 - an access channel is any one of 31 channels. Each access channel is comprised of a single E1 time slot. T. Cox (editor) Expires 12/31/93 [Page 11] Internet Draft Frame Relay Service MIB May 12, 1993 o Fractional E1 - an access channel is a grouping of N E1 time slots (NX64 Kbps, where N = 1-30 E1 time slots per FE1 access channel) that may be assigned in consecutive or non-consecutive order. Within a given unformatted line, the entire unformatted line is considered an access channel. Examples include RS-232, V.35, V.36 and X.21 (non- switched). Forward - Forward direction data traffic is traffic flowing from the originating access channel to the terminating access channel. This is illustrated in Figure 2. Originating - Originating refers to the access channel from which the virtual connection is initiated. In a multi-network PVC, each PVC segment has an originating access channel and terminating access channel for each network that the multi- network PVC traverses. See Figure 1. Permanent Virtual Connection (PVC) - A virtual connection that has its endpoints and bearer capabilities defined at subscription time. Terminating - Terminating refers to the access channel at which the virtual connection stops. In a multi-network PVC, each PVC segment has an originating access channel and terminating access channel for each network that the multi- network PVC traverses. See Figure 1. Time slot (E1) - An octet within the 256-bit information field in each E1 frame is defined as a time slot. Time slots are position sensitive within the 256-bit information field. Fractional E1 service is provided in contiguous or non- contiguous time slot increments. Time slot (T1) - An octet within the 192-bit information field in each T1 frame is defined as a time slot. Time slots are position sensitive within the 192-bit information field. Fractional T1 service is provided in contiguous or non- contiguous time slot increments. T. Cox (editor) Expires 12/31/93 [Page 12] Internet Draft Frame Relay Service MIB May 12, 1993 UNI NNI NNI UNI | | | | | | | | | PVC Segment 1 | PVC Segment 2 | PVC Segment 3 | |<------------->|<------------->|<------------->| | | | | | +-----------+ | +-----------+ | +-----------+ | | | | | | | | | | | Originating | | | | | | | | | |Terminating +--------+ | | Network I | | | Network J | | | Network K | | +--------+ | | | | | | | | | | | | | | | User A | | | | | | | | | | | | | | |----| |---| |---| |----| User B | | | | | O T | | | O T | | | O T | | | | | ////////////////////////////////////////////////////////////// | | | | | | | | | | | | | | | +--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+ | | | | | | | Multi-network PVC | |<------------------------------------------->| | NNI = Network-to Network Interface | | UNI = User-to-Network Interface Figure 1 Multi-network PVC T. Cox (editor) Expires 12/31/93 [Page 13] Internet Draft Frame Relay Service MIB May 12, 1993 UNI UNI | | | | | CIR-fwd, Bc-fwd, Be-fwd | |--------------------------------------------->>| | NNI NNI | | +-----------+ | +-----------+ | +-----------+ | | | | | | | | | | | Originating | | | | | | | | | |Terminating +--------+ | | Network I | | | Network J | | | Network K | | +--------+ | | | | | | | | | | | | | | | User A | | | | | | | | | | | | | | |----| |---| |---| |----| User B | | | | | O T | | | O T | | | O T | | | | | ////////////////////////////////////////////////////////////// | | | | | | | | | | | | | | | +--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+ | | | | | | | CIR-bwd, Bc-bwd, Be-bwd | |<<---------------------------------------------| Figure 2 A Multi-network PVC T. Cox (editor) Expires 12/31/93 [Page 14] Internet Draft Frame Relay Service MIB May 12, 1993 +-------------------------------------+ | Customer Network Management Station | | (SNMP based) | +-------------------------------------+ /| /| /| | | | UNI / NNI / NNI / UNI | +-----------+ | +-----------+ | +-----------+ | | | | | | | | | | | Originating | | | | | | | | | |Terminating +--------+ | | Network I | | | Network J | | | Network K | | +--------+ | | | | | | | | | | | | | | | User A | | | | | | | | | | | | | | |----| |---| |---| |----| User B | | | | | O T | | | O T | | | O T | | | | | ////////////////////////////////////////////////////////////// | | | | | | | | | | | | | | | +--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+ | | | | Figure 3 Managing a Multi-network PVC T. Cox (editor) Expires 12/31/93 [Page 15] Internet Draft Frame Relay Service MIB May 12, 1993 6. Object Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter FROM RFC1155-SMI DisplayString FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in RFC 1212. frnetserv OBJECT IDENTIFIER ::= { experimental 45 } T. Cox (editor) Expires 12/31/93 [Page 16] Internet Draft Frame Relay Service MIB May 12, 1993 -- The Frame Relay Service Channel Group -- Implementation of this group is mandatory for all systems -- that perform Frame Relay Services. -- This group has two tables: -- Frame Relay Channel Information -- Frame Relay Channel Errors -- the Frame Relay Channel Information frChanTable OBJECT-TYPE SYNTAX SEQUENCE OF FrChanEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Frame Relay Channel Information table." ::= { frnetserv 1 } frChanEntry OBJECT-TYPE SYNTAX FrChanEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the Frame Relay Channel Information table." INDEX { frChanIfIndex } ::= { frChanTable 1 } FrChanEntry ::= SEQUENCE { frChanIfIndex INTEGER, frChanNumPlan INTEGER, frChanNetAddress OCTET STRING, frChanContact DisplayString, frChanLocation DisplayString, frChanIfType INTEGER, frChanIfSpecific T. Cox (editor) Expires 12/31/93 [Page 17] Internet Draft Frame Relay Service MIB May 12, 1993 OBJECT IDENTIFIER, frChanQ922AddLen INTEGER, frChanDLCILen INTEGER, frChanSigState INTEGER, frChanSigProced INTEGER, frChanSigUserN391 INTEGER, frChanSigUserN392 INTEGER, frChanSigUserN393 INTEGER, frChanSigUserT391 INTEGER, frChanSigNetN392 INTEGER, frChanSigNetN393 INTEGER, frChanSigNetT392 INTEGER, frChanSigNetnN4 INTEGER, frChanSigNetnT3 INTEGER } frChanIfIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to MIB II's ifIndex value for this UNI/NNI access channel." ::= { frChanEntry 1 } frChanNumPlan OBJECT-TYPE SYNTAX INTEGER { e164(1), x121(2), other(3) } ACCESS read-only T. Cox (editor) Expires 12/31/93 [Page 18] Internet Draft Frame Relay Service MIB May 12, 1993 STATUS mandatory DESCRIPTION "The value of this object identifies the numbering plan that is used to identify the UNI/NNI access channel." ::= { frChanEntry 2 } frChanNetAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..8)) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the UNI/NNI access channel." ::= { frChanEntry 3 } frChanContact OBJECT-TYPE SYNTAX DisplayString (SIZE(0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the network contact for this UNI/NNI access channel." ::= { frChanEntry 4 } frChanLocation OBJECT-TYPE SYNTAX DisplayString (SIZE(0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the network location for this UNI/NNI access channel." ::= { frChanEntry 5 } frChanIfType OBJECT-TYPE SYNTAX INTEGER { uni(1), nni(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the type of network interface for this access channel." ::= { frChanEntry 6 } T. Cox (editor) Expires 12/31/93 [Page 19] Internet Draft Frame Relay Service MIB May 12, 1993 frChanIfSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is the OID for the MIB directly below the Frame Relay Layer for this access channel. This MIB, for example, may be the DS1 MIB or the ATM MIB." ::= { frChanEntry 7 } frChanQ922AddLen OBJECT-TYPE SYNTAX INTEGER { twoOctets(1), threeOctets(2), fourOctets(3) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the address length for frame relay frames for this access channel." ::= { frChanEntry 8 } frChanDLCILen OBJECT-TYPE SYNTAX INTEGER { tenBits(1), sixteenBits(2), seventeenBits(3), twentyThreeBits(4) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the DLCI length for frame relay frames for this access channel." ::= { frChanEntry 9 } frChanSigState OBJECT-TYPE SYNTAX INTEGER { ccittQ933A(1), ansiT1617D(2), lmi(3), T. Cox (editor) Expires 12/31/93 [Page 20] Internet Draft Frame Relay Service MIB May 12, 1993 q933AnsiT1617B(4), none(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Local In-Channel Signaling Protocol that is used for this access channel." ::= { frChanEntry 10 } frChanSigProced OBJECT-TYPE SYNTAX INTEGER { u2nuser(1), u2nnet(2), bidirect(3) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Local In-Channel Signaling Procedure that is used for this access channel. The access channel can be performing user-to-network user-side procedures, user-to-network network-side procedures, or bidirectional procedures." ::= { frChanEntry 11 } frChanSigUserN391 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the User-side N391 value for this access channel. If the access channel is not performing user-side procedures, then this value is zero." DEFVAL { 6 } ::= { frChanEntry 12 } frChanSigUserN392 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION T. Cox (editor) Expires 12/31/93 [Page 21] Internet Draft Frame Relay Service MIB May 12, 1993 "The value of this object identifies the User-side N392 value for this access channel. If the access channel is not performing user-side procedures, then this value is zero." DEFVAL { 3 } ::= { frChanEntry 13 } frChanSigUserN393 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the User-side N393 value for this access channel. If the access channel is not performing user-side procedures, then this value is zero." DEFVAL { 4 } ::= { frChanEntry 14 } frChanSigUserT391 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the User-side T391 value for this access channel. If the access channel is not performing user-side procedures, then this value is zero." DEFVAL { 10 } ::= { frChanEntry 15 } frChanSigNetN392 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Network- side N392 value for this access channel. If the access channel is not performing network-side procedures, then this value is zero." DEFVAL { 3 } ::= { frChanEntry 16 } frChanSigNetN393 OBJECT-TYPE SYNTAX INTEGER (0..20) T. Cox (editor) Expires 12/31/93 [Page 22] Internet Draft Frame Relay Service MIB May 12, 1993 ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Network- side N393 value for this access channel. If the access channel is not performing network-side procedures, then this value is zero." DEFVAL { 4 } ::= { frChanEntry 17 } frChanSigNetT392 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Network- side T392 value for this access channel. If the access channel is not performing network-side procedures, then this value is zero." DEFVAL { 15 } ::= { frChanEntry 18 } frChanSigNetnN4 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Network- side nN4 value for this access channel. If the access channel is not performing network-side procedures or is not performing lmi procedures, then this value is zero." ::= { frChanEntry 19 } frChanSigNetnT3 OBJECT-TYPE SYNTAX INTEGER (0..20) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the Network- side nT3 value for this access channel. If the access channel is not performing network-side procedures or is not performing lmi procedures, then this value is zero." ::= { frChanEntry 20 } T. Cox (editor) Expires 12/31/93 [Page 23] Internet Draft Frame Relay Service MIB May 12, 1993 -- the Frame Relay Channel Errors frChanErrorsTable OBJECT-TYPE SYNTAX SEQUENCE OF FrChanErrorsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Frame Relay Channel Errors table." ::= { frnetserv 2 } frChanErrorsEntry OBJECT-TYPE SYNTAX FrChanErrorsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the Frame Relay Channel Errors table." INDEX { frChanErrorsIfIndex } ::= { frChanErrorsTable 1 } FrChanErrorsEntry ::= SEQUENCE { frChanErrorsIfIndex INTEGER, frChanErrorsTooLongFrames Counter, frChanErrorsCRCErrors Counter, frChanErrorsHDLCAborts Counter, frChanErrorsSigLinkRelRespErrors Counter, frChanErrorsSigProtRespErrors Counter, frChanErrorsSigInactiveResps Counter, frChanErrorsSigLinkRelInitErrors Counter, frChanErrorsSigProtInitErrors Counter, frChanErrorsSigInactiveInits Counter } frChanErrorsIfIndex OBJECT-TYPE T. Cox (editor) Expires 12/31/93 [Page 24] Internet Draft Frame Relay Service MIB May 12, 1993 SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to MIB II's ifIndex value for this UNI/NNI access channel." ::= { frChanErrorsEntry 1 } frChanErrorsTooLongFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frame relay frames received that were too long for this UNI/NNI access channel." ::= { frChanErrorsEntry 2 } frChanErrorsCRCErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frame relay frames received that had CRC errors for this UNI/NNI access channel." ::= { frChanErrorsEntry 3 } frChanErrorsHDLCAborts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frame relay HDLC frames received that were aborted for this UNI/NNI access channel." ::= { frChanErrorsEntry 4 } frChanErrorsSigLinkRelRespErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of local in-channel signaling link reliability errors that were responding to polls for this UNI/NNI access channel." ::= { frChanErrorsEntry 5 } T. Cox (editor) Expires 12/31/93 [Page 25] Internet Draft Frame Relay Service MIB May 12, 1993 frChanErrorsSigProtRespErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of local in-channel signaling protocol errors that were responding to polls for this UNI/NNI access channel." ::= { frChanErrorsEntry 6 } frChanErrorsSigInactiveResps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times the channel declared inactive responding to polls (i.e., N392 errors in N393 events) for this UNI/NNI access channel." ::= { frChanErrorsEntry 7 } frChanErrorsSigLinkRelInitErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of local in-channel signaling link reliability errors that were initiating polls for this UNI/NNI access channel." ::= { frChanErrorsEntry 8 } frChanErrorsSigProtInitErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of local in-channel signaling protocol errors that were initiating polls for this UNI/NNI access channel." ::= { frChanErrorsEntry 9 } frChanErrorsSigInactiveInits OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION T. Cox (editor) Expires 12/31/93 [Page 26] Internet Draft Frame Relay Service MIB May 12, 1993 "The number of times the channel declared inactive initiating polls (i.e., N392 errors in N393 events) for this UNI/NNI access channel." ::= { frChanErrorsEntry 10 } T. Cox (editor) Expires 12/31/93 [Page 27] Internet Draft Frame Relay Service MIB May 12, 1993 -- The Frame Relay PVC Group -- Implementation of this group is mandatory for all systems -- that perform Frame Relay Services. -- the Frame Relay PVC Information frPVCTable OBJECT-TYPE SYNTAX SEQUENCE OF FrPVCEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The Frame Relay PVC table." ::= { frnetserv 3 } frPVCEntry OBJECT-TYPE SYNTAX FrPVCEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the Frame Relay PVC table." INDEX { frPVCIfIndex, frPVCDLCIIndex } ::= { frPVCTable 1 } FrPVCEntry ::= SEQUENCE { frPVCIfIndex INTEGER, frPVCDLCIIndex INTEGER, frPVCLocalOrient INTEGER, frPVCRemoteIfIndex INTEGER, frPVCRemoteDLCIIndex INTEGER, frPVCRemoteNetAddress OCTET STRING, frPVCAdminStatus INTEGER, frPVCOperStatus INTEGER, frPVCSegmentNumber INTEGER, frPVCRcvdSigStatus T. Cox (editor) Expires 12/31/93 [Page 28] Internet Draft Frame Relay Service MIB May 12, 1993 INTEGER, frPVCAccountUnitSize INTEGER, frPVCInFrames Counter, frPVCOutFrames Counter, frPVCOutAccUnits Counter, frPVCBcDiscardState INTEGER, frPVCBcDiscardStateTimes Counter, frPVCFwdBc INTEGER, frPVCFwdBe INTEGER, frPVCFwdCIR INTEGER, frPVCBwdBc INTEGER, frPVCBwdBe INTEGER, frPVCBwdCIR INTEGER, frPVCMaxFrameSize INTEGER } frPVCIfIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to MIB II's ifIndex value for this UNI/NNI access channel." ::= { frPVCEntry 1 } frPVCDLCIIndex OBJECT-TYPE SYNTAX INTEGER (1..8388608) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the DLCI value for this UNI/NNI access channel - PVC pair." T. Cox (editor) Expires 12/31/93 [Page 29] Internet Draft Frame Relay Service MIB May 12, 1993 ::= { frPVCEntry 2 } frPVCLocalOrient OBJECT-TYPE SYNTAX INTEGER { originating(1), terminating(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object provides the orientation of this PVC through the network for this UNI/NNI access channel - PVC pair. This information helps to determine which direction is forward and backwards; originating to terminating is forwards, and terminating to originating is backwards." ::= { frPVCEntry 3 } frPVCRemoteIfIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to MIB II's ifIndex value for the remote UNI/NNI access channel." ::= { frPVCEntry 4 } frPVCRemoteDLCIIndex OBJECT-TYPE SYNTAX INTEGER (1..8388608) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the DLCI value for the remote UNI/NNI access channel - PVC pair." ::= { frPVCEntry 5 } frPVCRemoteNetAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..8)) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the remote UNI/NNI access channel." T. Cox (editor) Expires 12/31/93 [Page 30] Internet Draft Frame Relay Service MIB May 12, 1993 ::= { frPVCEntry 6 } frPVCAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), inactive(3), testing(4), notInService(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the administrative status of this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 7 } frPVCOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2), inactive(3), testing(4), notInService(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the operational status of this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 8 } frPVCSegmentNumber OBJECT-TYPE SYNTAX INTEGER (1..255) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the PVC segment number for this PVC segment for this UNI/NNI access channel - PVC pair. As a PVC traverses multiple networks, each PVC segment (i.e., each network) will be numbered starting with the first network in the forward direction. T. Cox (editor) Expires 12/31/93 [Page 31] Internet Draft Frame Relay Service MIB May 12, 1993 The numbering should start at one and go to N, where N is the Nth network in the chain." ::= { frPVCEntry 9 } frPVCRcvdSigStatus OBJECT-TYPE SYNTAX INTEGER { active(1), inactive(2), deleted(3), none(4) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the PVC status received via the local in-channel signaling procedures for this UNI/NNI access channel - PVC pair. This object is only is only pertinent for bidirectional procedures and user-to-network user side procedures. For user-to-network network side procedures, the value of this object should be none." ::= { frPVCEntry 10 } frPVCAccountUnitSize OBJECT-TYPE SYNTAX INTEGER (1..255) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies the the accounting unit size for this UNI/NNI access channel - PVC pair. The accounting unit size is equal to a block of octets." ::= { frPVCEntry 11 } frPVCInFrames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frames received for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 12 } frPVCOutFrames OBJECT-TYPE T. Cox (editor) Expires 12/31/93 [Page 32] Internet Draft Frame Relay Service MIB May 12, 1993 SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of frames sent for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 13 } frPVCOutAccUnits OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of accounting units sent for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 14 } frPVCBcDiscardState OBJECT-TYPE SYNTAX INTEGER { yes(1), no(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object identifies whether this UNI/NNI access channel - PVC pair is in a Bc discard state." ::= { frPVCEntry 15 } frPVCBcDiscardStateTimes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times this UNI/NNI access channel - PVC pair has been in a Bc discard state." ::= { frPVCEntry 16 } frPVCFwdBc OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the forward T. Cox (editor) Expires 12/31/93 [Page 33] Internet Draft Frame Relay Service MIB May 12, 1993 Bc for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 17 } frPVCFwdBe OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the forward Be for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 18 } frPVCFwdCIR OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the forward CIR for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 19 } frPVCBwdBc OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the backward Bc for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 20 } frPVCBwdBe OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the backward Be for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 21 } frPVCBwdCIR OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the backward T. Cox (editor) Expires 12/31/93 [Page 34] Internet Draft Frame Relay Service MIB May 12, 1993 CIR for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 22 } frPVCMaxFrameSize OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "The value of this object is equal to the maximum frame size for this UNI/NNI access channel - PVC pair." ::= { frPVCEntry 23 } END T. Cox (editor) Expires 12/31/93 [Page 35] Internet Draft Frame Relay Service MIB May 12, 1993 7. Acknowledgments This document was produced by the Frame Relay Service MIB Working Groups: Special thanks goes to the Frame Relay Forum Technical Committee for its participation in writing this MIB. T. Cox (editor) Expires 12/31/93 [Page 36] Internet Draft Frame Relay Service MIB May 12, 1993 8. References [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. [3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, Performance Systems International, March 1991. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. T. Cox (editor) Expires 12/31/93 [Page 37] Internet Draft Frame Relay Service MIB May 12, 1993 9. Security Considerations Security issues are not discussed in this memo. 10. Authors' Addresses Tracy A. Cox Bell Communications Research 331 Newman Springs Road P.O. Box 7020 Red Bank, NJ 07701-7020 Phone: (908) 758-2107 EMail: tacox@mail.bellcore.com T. Cox (editor) Expires 12/31/93 [Page 38] Internet Draft Frame Relay Service MIB May 12, 1993 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 The Network Management Framework ...................... 2 4 Objects ............................................... 3 4.1 Format of Definitions ............................... 3 5 Overview .............................................. 4 5.1 Apply MIB II to a Frame Relay Service ............... 5 5.2 Apply the DS1/E1 MIB to Frame Relay Service ......... 7 5.3 Frame Relay Service MIB Terminology ................. 11 6 Object Definitions .................................... 16 6.1 The Frame Relay Service Channel Group ............... 17 6.1.1 The Frame Relay Channel Information ............... 17 6.1.2 The Frame Relay Channel Errors .................... 24 6.2 Frame Relay PVC Group ............................... 28 7 Acknowledgments ....................................... 36 8 References ............................................ 37 9 Security Considerations ............................... 38 10 Authors' Addresses ................................... 38 T. Cox (editor) Expires 12/31/93 [Page 39]